I suggest that (for consistency with other profiles/standards) providers must support action based filtering and should support handle based filtering for the history service. So the protocol should support this somehow (see suggestion for one approach in another comment).

Because the history service is a foundational feature that may be used by large and small participants in the future, a little flexibility seems worthwhile even if the business cases aren't 100% clear at the beginning. I know low-resource providers would prefer that consumers only request what they need but providers have no control over that and best they can do is support the mechanisms.

Implementation doesn't seem hard to me if there is a mechanism in the protocol but I don't feel very strongly about this. Mostly because it requires consumers to use it for providers to benefit, which may not happen in practice.

I suggest that (for consistency with other profiles/standards) providers must support action based filtering and should support handle based filtering for the history service.

Action based filtering does not have any meaningful effect on this port type as there is only one notification in there: To enable subscribing to one or more Notifications exposed by a HOSTED SERVICE, this profile defines a Filter Dialect designated "http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01/Action". You would either be able to select everything or nothing - to select nothing, just do not send s subscribe :-)

Handle based filtering may be applicable to the history service, however, it is an optional feature in SDC Glue. I do not see embedded devices performing handle-based filtering on huge amounts of historic data. The limited filtering comes at a cost: less flexibility. But it provides embedded devices with the ability to efficiently store their historic data without performing expensive filtering operations when requested. If we receive proof that such an operation is efficiently processable and needed by the market today, I am totally happy to add it as a mandatory feature to the history service. The things for which there is no demand by the market, I would like to keep it out the spec for as long as possible. It's all big enough already...

a little flexibility seems worthwhile even if the business cases aren't 100% clear at the beginning.

Flexibility is always given - the current filter can be replaced by another one that supports nifty filtering options if we realize, the limited filtering does not suffice. Let's be evolutionary over revolutionary. ;-)

For action based filtering, I'm thinking of the StateEventService/EpisoidicMetricReport, StateEventService/EpisoidicAlertReport, ContextService/EpisoidicContextReport, etc. That is a consumer might decide they only want alert history from the day, then retrieve metric history for particular epochs around an alert.

We currently do handle based filtering on embedded devices. Mostly because 20701:R0039 said we should. Its only useful if consumers follow 20701:R0037 though and so far I haven't found any to validate interoperability of our prototype implementation unfortunately.

We don't have additional overhead to apply the filter (that is, everything is filtered anyway) and it would be fine in our prototype history service if there was a way to do communicate selection. Mdibs in embedded devices may be smaller making handling filtering easier, though that's also the use-case that could benefit from the most from reduced traffic. Maybe handle filtering is only useful for embedded devices? Assuming consumer's take advantage of it (and there's no way to tell if it is available; makes me think should requirements are a little pointless for feature support).

Anyway, your right; new features can always be added and things can be changed. That can take a while, though, and this is just one opportunity to do that but I don't feel strongly about it either way.

Added proposed solution to schema.

NOTE: The time interval is a hint. A <<vol1_spec_sdpi_p_actor_somds_provider>> may respond with data that exceeds, or is a subset of, the interval of ++[hm:TimeRange/@starttime, hm:TimeRange/@EndTime]++.

For clarity:

… or filter request that point into the future.

… or the filter requests reports from the future.

simplify for clarity:

The <<vol1_spec_sdpi_p_actor_somds_provider>> transmitting <<term_historic_localized_text>> shall transmit filtered <<term_historic_localized_text>>s before transmitting hm:HistoricMdib or hm:HistoricReport elements that reference the <<term_historic_localized_text>>s.

Note:
This ensures the localized text is available to the <<vol1_spec_sdpi_p_actor_somds_consumer>> before it is used by other elements.

I think it is worth pointing this out explicitly:

NOTE: A <<vol1_spec_sdpi_p_actor_somds_provider>> may respond with a subset of data that is not contiguous. For example, a complete history of waveform streams may not be available.

Copy from R0516 for consistency.

<xsd:element name="Reports" type={space delimited list of desired reports from an enumerated type of reports}...

For example: <Reports>EpisodicMetricReport EpisodicAlertReport</Reports>

Documentation: A space separate list of reports the subscriber is interested in; implied value is all reports. This is a hint to the provider that it may drop reports, e.g., WaveformStream, that are not in the list without impacting the subscribers goals to reduce bandwidth, etc.

<xsd:element name="Handles" type={a white space delimited list of type pm:HandleRef}... <documentation>This is a hint of the containment tree entries desired by the subscriber. The provider may drop reports that don't include the desired entries to reduce bandwidth, etc. The implied value is all reports.</documentation>.

Is ok, however, this must be an optional feature as providers may not be able to filter on such granularity (there are implementations out there just storing zipped content and will never unpack and re-zip just because a consumer requested so).

Agreed. Calling it a "Hint" was my idea to make clear that providers are free to ignore the suggestion if it doesn't suit them.

This seems to require providers to process a filter node that can include, along with the hm:HistoryQuery element, an unbounded and undefined set of other elements. Is that the intention?

How about:

A filter in the Dialect designated urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.3.1.1 contains exactly, and only, one hm:QueryFilter of type hm:QueryFilterType.

It seems better to give a concrete specification, and amend it in later versions, if necessary to me. Otherwise, to ensure interoperability, I think we should alert manufacturers that the content can change at any time. Perhaps with a note:

NOTE: The filter may include additional elements and attributes from any namespace, viz:

<xs:complexType name="FilterType" mixed="true"> 
  <xs:sequence> 
    <xs:any namespace="##other" processContents="lax" 
                 minOccurs="0" maxOccurs="unbounded" /> 
    </xs:sequence> 
    <xs:attribute name="Dialect" type="xs:anyURI" use="optional" /> 
    <xs:anyAttribute namespace="##other" processContents="lax" /> 
</xs:complexType>

Added proposed solution to schema.